Digital audio/video (A/V) input/output (I/O) devices are employed in various demanding applications including motion picture, video game console, Internet appliance, and PC multimedia applications. Such applications often require transfer of A/V data and commands between A/V I/O devices and associated A/V systems.
Typically, an A/V system includes an A/V controller, an A/V file system, and a physical storage driver. An A/V I/O device, such as a camcorder, generally communicates with the A/V controller to forward to the A/V controller the desired A/V commands to be executed. Upon receiving the A/V commands, the A/V controller then directs the A/V file system to act accordingly. The communication between the A/V controller and the A/V file system can be, for example, implemented using an application programming interface. An example of such application programming interface is disclosed in co-pending U.S. patent application Ser. No. 10/005884, entitled “APPLICATION PROGRAMMING INTERFACE FOR COMMUNICATION BETWEEN AUDIO/VIDEO FILE SYSTEM AND AUDIO/VIDEO CONTROLLER,” filed concurrently herewith, which claims the benefit of priority from U.S. Provisional Patent Application Ser. No. 60/272,863, entitled “APPLICATION PROGRAMMING INTERFACE FOR COMMUNICATION BETWEEN ADUIO/VIDEO FILE SYSTEM AND AUDIO/VIDEO CONTROLLER” by Duruoz et al., filed on Mar. 1, 2001, the disclosures of which are incorporated in their entirety by reference herein.
In accordance with the desired A/V commands received from the A/V controller, the A/V file system then, in turn, directs the physical storage driver to process the necessary A/V data. For example, the physical storage driver may output certain A/V data to the A/V I/O device for display, or alternately, it may record A/V data received from the A/V I/O device. Similarly, the communication between the A/V file system and the physical storage driver can also be implemented using an application programming interface. An example of such application programming interface is disclosed in co-pending U.S. Provisional Patent Application Ser. No. 60/272,798, entitled “APPLICATION PROGRAMMING INTERFACE FOR COMMUNICATION BETWEEN AUDIO/VIDEO FILE SYSTEM AND HARD DISK DRIVE SOFTWARE” by Duruoz et al., filed on Mar. 1, 2001. Since the A/V file system is required to communicate with both the A/V controller and the physical storage driver, it would be desirable to provide an A/V file system that is capable of optimizing communications with other devices.
Furthermore, A/V files typically comprise sequential time-dependent data frames. Time-dependent files, such as A/V files, are generally called isochronous files. These isochronous files are usually very large. On the other hand, non time-dependent files, such as word processor and spreadsheet files, are generally called asynchronous files and they are relatively small. Both types of files, isochronous and asynchronous, are usually stored on the same physical storage medium, such as a hard disk.
As mentioned above, the A/V file system communicates with the physical storage driver to control data access and handling. Consequently, the A/V file system is often required to accommodate large A/V files and small asynchronous files on the same disk. Unfortunately, existing file systems are typically optimized to handle only either A/V files or small asynchronous files, but not both. File systems optimized for small asynchronous files are often susceptible to A/V data corruption or glitches in A/V playback resulting from unexpected data retrieval delays. On the other hand, file systems optimized for A/V data often inefficiently handle small asynchronous files.
Hard disks and accompanying file systems used for A/V applications are often optimized for small asynchronous files. These file systems often only support either file allocation table (FAT) or FAT disks. Each FAT corresponds to a given disk. The given disk is generally divided into clusters or blocks. A FAT contains a number of indices. Each FAT index corresponds to a cluster or block within the given disk. Since a cluster or block is the smallest addressable unit within the given disk, a file may occupy a hard disk cluster specified by a FAT index even if the file size is much smaller than the cluster size. The difference between the cluster size and the file size represents wasted space. Consequently, these fixed FAT's may cause inefficient disk memory allocation, especially in file systems employed for both small and large files.
Generally, a file system facilitates file organization, creation, deletion, saving, and updating. File systems often employ file system operating systems and associated directory structures to facilitate file system operations. To avoid A/V playback glitches, file system operating systems must coordinate file access and retrieval operations to accommodate delays between code or command execution and disk access. For example, if a file system is directed to execute a playback operation, a delay exists between the execution of the playback command and data retrieval from the disk. This delay need to be effectively accommodated to avoid A/V playback glitches or data corruption.
Furthermore, many A/V I/O devices, such as camcorders, communicate with A/V systems via IEEE 1394 serial links. Such serial links may place additional time constraints on A/V disk access and retrieval operations. Conventional file systems that are optimized for asynchronous files may not effectively meet the time constraints, resulting in data corruption or glitches in the A/V playback.
As A/V technology advances, file sizes increase with the resolution of A/V data. The larger files create further delays between command execution and disk access, which may exacerbate glitches in A/V data streams handled by conventional file systems and associated operating systems. File system technology, therefore, need to keep up with improving A/V technology to maintain efficient file system operation. Hence, it would be desirable to provide an A/V file system that is capable of efficiently handling both asynchronous and isochronous files thereby minimizing delays between command execution and disk access.